UNITED STATES DEPARTMENT OF COMMERCE^^ " 
gUnited States Patent and Trademark Office 

November ^f^^^- 



fC^G DATR ""^^ ^™ REQUmEMENxl TO B^^^ A 



NUMBER: 60/516,385 
FnJNG DATE: October 31, 2003 

RELATED PCt APPLICATION NUMBER: PCT/US04/36179 



Certified by 








■ 


















-== Jon 


W Dudas 





lActing Under Secretary of Commerce 
gfor Intel lectiial Property 
|and Acting Director of the U.S. 
|Patent and Trademark Office 



•0 

O 



PROVISIONAL APPLICATION FOR PATENT COVER SHEET 



Docket No. 

03-930 



INVENTOR(S)/APPUCANTS(S) 



This is a request for fiiing a PROVISiONAL APP LICATION FOR PATENT under 37 CFR § t,53fcj. 
Express Mail No. EV334649138US 



Type a plus sign (♦) 
Inside this box: 



LAST NAME 



Wigdor 



TITLE OF THE INVENTION (280 character maximum) 



FIRST NAME 



Daniel 



MIDDLE 
INniAL 



RESIDENCE 

(City and either state or foreign country) 



Toronto, Canada 



.00 

CO 
xiCO 

M 



I Concurrent Data Entry for a Portable Device 



CUSTOMER NUMBER 



r 



20306 

McDonnell Boehnen Hulbert & Berghoff 



ENCLOSED APPUCATiON PARTS (check all that apply) 



IS Specification Number of Pages 30 
^ Other: Application Data Sheet (2 pages) 



IS Drawings Number of Sheets 6 



METHOD OF PAYMENT FOR THIS PROVISIONAL APPLICATION FOR PATENT 



S Applicant claims small entity status. See 37 CFR 1 ,27 

El A check or money order is enclosed to cover the Provisional 
Filing Fee. 

H The Commissioner is hereby authorized to charge filing fees and 
credit Deposit Account Number: 13-2490. 



CERTIFICATE OF MAIUNG 



PROVISIONAL 
APPLICATION FOR 
PATENT FILING FEE 
AMOUNT ($) 



80.00 



SCO 
iO 



IS 



I hereby certify that, under 37 CFR § 1.10, I directed that the correspondence Identified above be 
deposited with the United States Postal Seivlce as "Express Mail Post Office to Addressee." addressed 
to IMaii Stop Provisional Patent Application, Commissioner for Patents. P.O. Box 1450. Alexandria 
Virginia 22313.1450. on the date indicated below. «i«anana, 



The invention tras irode by an agency o» the United States Government or under a contract with an agency of ths United Stales GmS!^ 
No- Yes. the name olthe U.S. Government agency and the Govemfflent contract number are: 



Respectfully submitted, 



SIGNATURE: 



submitted, 



Date: October 31.2003 



TYPED or PRINTED NAME Marcus J. Thvmian rEG. NO. 43.954 

□ Additional inventors are being named on separately numbered sheets attached hereto. 



APPLICATION FOR A UNITED STATES PATENT 

PROVISIONAL 

UNITED STATES PATENT AND TRADEMARK OFFICE 
MBHB Case No. 03-930 

Title: CONCURRENT DATA ENTRY FOR A PORTABLE DEVICE 

biventOTS: Daniel Wigdor 

Assignee: Iota Wireless 



1 



CONCURRENT DATA ENTRY FOR A PORTABLE DEVICE 

FIELD 

The present invention relates to data entry on a portable device, and more 
particularly, to a system and method of concurrent data entry for a portable device, such 
as a mobile phone. 

BACKGROUND OF THE INVFNTinN 
Most mobile phones are equipped with a simple 12.button keypad, similar to the 
keypad 100 shown in FIG. 1. Such a keypad is an inherently poor tool for generating 
phrases for a 26-letter alphabet. Using traditional text-entry techniques, such as MulHTap, 
an average text message of 7 words requires roughly 70 key presses. The GSM 
Association fwww. asm world rnm^ estimates that in 2003, nearly 500 billion text 
messages will be sent worldwide from mobile phones. Using current text-entry 
techniques, this would require approximately 35 trillion keypresses. While research has 
gone into devising a variety of more efficient text input techniques, none has yet emerged 
as a new standard. 

Entering text from the 26 character English alphabet (or practically any other 
Roman alphabet) using the standard 12-key (0-9,*,#) mobile phone keypad forces a 
mapping of more than one character per key. The typical mapping has keys 2-9 
representing either three or four alphabetic characters in addition to the numerals. All 
text input techniques that use this standard keypad have to somehow resolve the 
ambiguity that arises from this multiplexed mapping. The problem may be characterized 
as involving two main tasks necessary for entering a character: between-group selection 
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of the appropriate group of characters, and within-group selection of the appropriate 
character within the previously chosen group. Most text input techniques to date can 
generally be divided into two categories: those that require multiple presses of a single 
key to make between-group followed by within-group selections, and those that require a 
single press of multiple keys to make these selections. Because both categories require 
consecutive key presses, the research focus has been on reducing the average number of 
key strokes per character ("KSPC") required to enter text. Advances in the area generally 
make language specific assumptions to "guess" the desired within-group character, thus 
reducing or eliminating the key presses required for the within-group selection. The 
success of these techniques, however, is based almost entirely on how closely the text 
entered conforms to the underiying language model. Given that text entered on mobile 
phones often involves significant abbreviations and even evolving new "languages" by 
frequent users of SMS messaging, making language assumptions may not be the best 
approach to solving the text input problem, 

A small number of mobile phones today utilize QWERTY style keypads that 
enable text entry with techniques similar to typing on a regular keyboard, albeit at a much 
smaller physical scale (e.g., the Nokia 5510, www.nokLa.cQmV More recently, hybrid 
devices that combine phones with Personal Digital Assistants ("PDAs"), such as the 
Handspring Treo (www.handsprinp.com^ and PocketPC Phone f www.microsoft.com V 
utilize pen-based text input techniques common to PDA*s such as Palm's Graffiti 
(www.palm.com). While these devices are making small inroads into the mobile phone 
market, the vast majority of mobile phones are equipped with the standard keypad, which 
has 12 keys: 0-9, and#. 
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Entering text fiiom a 26 character alphabet using this keypad forces a mapping of 
more than one character per button of the keypad. A typical mapping has keys 2-9 
representing either three or four characters, with space and punctuation mapped to the 
other buttons. All text input techniques that use this standard keypad have to somehow 
resolve the ambiguity that arises from this multiplexed mqiping. There are three main 
techniques for overcoming this ambiguity: MuUiTap, two-key, and linguistic 
disambiguation. 

1. MuUiTap 

MultiTap works by requiring the user to make multiple presses of each key to 
indicate which letter on that key is desired. For example, the letters pqrs traditionally 
appear on the "7" key. Pressing that key once yields "p", twice "q", etc. A problem 
arises when the user attempts to enter two consecutive letters on the same button. For 
example, tapping the "2" key three times could resuh in either "c" or "ab". To overcome 
this, MultiTap employs a time-out on the button presses, typically 1-2 seconds, so that not 
pressing a button for the length of the timeout indicates that you are done entering that 
letter. Entering "ab" under this scheme has the user press the *'2" key once for "a", wait 
for the timeout, then press "2" twice more to enter "b". To overcome the time overhead 
this incurs, many implementations add a "timeout kill" button that allows the user to skip 
the timeout. If we assume that "0" is the timeout kill button, this makes the sequence of 
button presses to enter "ab": "2-0-2-2". MultiTap eliminates any ambiguity, but can be 
quite slow, with a keystrokes per character (KSPC) rate of approximately 2.03. (See 
MacKenzie, LS. (2002). KSPC (keystrokes per character) as a characteristic of text entry 
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techniques. Fourth International Symposium on Human-Computer Interaction with 
Mobile Devices, p. 1 95-2 1 0.) 

2. Two-Key Disambiguation 

The two-key technique requires the user to press two keys in quick succession to 
enter a character. The first keypress selects the app,x,priate g«,up of characters, while the 
second identifies the position of the desired character within that group. For example, to 
enter the character "e", the user presses the "3» key to select the g.x,up "def followed by 
the ••2" key since "e" is in the second position within the group. This technique, while 
quite simple, has failed to gain popularity for Roman alphabets. It has an obvious KSPC 
rate of 2. 

3. Linguistic Disambiguation 

There are a number of linguistic disambiguation schemes that utilize knowledge 
ofthe language to aid the text entry process. One example is IV (see Megicxom). 
which renders all possible pennutations of a sequence of button presses and looks them 
up in a dictionary. For example, the key sequence "5-3-8" could indicate any of 27 
possible renderings (3x3x3 letters on each of those keys). Most of these renderings have 
no meaning, and so are rejected. Looking each of them up in a dictionary tells the system 
that only "jet" is an English word, and so it is the one rendered. Ambiguity can. 

however, arise if there is more than one validrendering in the language, in which case the 
most common is presented. For example, the sequence "6-6" could indicate either "on" 
or "no". If the system renders the wrong word, a "next" key allows the user to cycle 
through the other valid permutations. An analysis of this technique for entering text ftom 
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an English coipus found a KSPC close to 1 (see MacKenzie, I.S. (2002) "KSPC 
(keystrokes per character) as a characteristic of text entry techniques," Fourth 
International Symposium on Human-Computer Interaction with Mobile Devices, pp. 1 95- 
210). Newer linguistic disambiguation techniques such as UtterWise and WordWise (see 
www.eatoni.com) also perfomi similarly well, with subtle advantages over earlier 
techniques. While these all have excellent KSPC rates, the success of linguistic-based 
systems depends on the assumption that users tend to enter 'TSnglish-like" words when 
sending text messages. However, users often use abbreviations and incomplete English 
when text messaging. Further, users of text messaging often communicate in acronyms 
or combinations of letters and numbers (e.g., "b4" for "before"). Another problem with 
these linguistic techniques is that users have to visually monitor the screen in order to 
resolve potential ambiguities, whereas the MultiTap and two-key techniques can be 
operated "eyes-free" by skilled users. 

Using Tilt Sensors in Portable Deuces 

Attempts have been made to incoiporate tilt sensors in portable devices. 
Unigesture uses tilt as an alternative to button pressing, eliminating the need for buttons 
for text entry. (See Sazawal. V., Want, R., & Borriello, G. (2002), 'The Unigesture 
Approach. One-Handed Text Entry for Small Devices," MobUe HCI, p. 256-270.) 
Rather than having the user make one of 8 ambiguous button presses (as is the present 
case with mobile phones). Unigesture has the user tilt the device in one of 7 directions to 
specify the group, or "zone", of the character that is desired. The ambiguity of the tilt is 
then resolved by using dictionary-based disambiguation. 
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TiltType combines button pressing and tilt for entering unambiguous text into a 
small, watch-like device with 4 buttons. (See Partridge. K., Chatterjee, S., Sazawal, V., 
Borriello, G., & Want, R. (2002), *TiltType: accelerometer-supported text entry for very 
small devices," ACM UIST Symposium on User Interface Software and Technology^ pp. 
201-204.) Pressing a button triggers an on-screen display of the characters that can be 
entered by tilting the device in one of eight directions. The user then makes the 
appropriate tilt and releases the button. 

Chording Keyboards 

Chording keyboards typically have a series of chording keys that can be used in 
conjunction with a keypad to enter text. Two-handed chorded keyboards have been used 
by the U.S. postal service for mail sorting, and are still used today by stenographers. The 
Twiddler (see www.handvkev.com^ and the Septambic Keyer (see 
wearcam.org/seplambic/) are examples of modem-day one-handed chording keyboards. 
Designed to be held in the hand while text is being entered, both are commonly used as 
part of a wearable computer. The Twiddler is equipped with 6 keys to be used with the 
thumb, and 12 for the fingers, while the traditional Septambic Keyer has just 3 thumb and 
4 finger switches. The Septambic Keyer allows for 47 different combinations of key 
presses, while the Twiddler allows over 80,000, though not all keys are used for text 
entry. 

None of the approaches described above have been conmiercially successful. 
What is needed is an efficient system and method for entering data into a numeric keypad 
of a portable device. 
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DETAILED DESCRIPTION 

In view of the wide variety of embodiments to which the principles of the present 
invention can be applied, it should be understood that the illustrated embodiments are 
exemplary only, and should not be taken as limiting the scope of the present invention. 

FIG. 2 is a pictorial representation of a mobile phone 200 according to an 
exemplary embodiment of the present invention. The phone 200 includes a 12-button 
keypad 202, a display 204, and an antenna 206. The phone 200 is also likely to include a 
microphone and speaker, which are not shown in FIG. 2. 

A user may tilt the phone 200 along a first axis 206 and/or a second axis 208 to 
assist in entering text data into the phone 200. By determining the tilt of the phone 200 
as the user is pressing a button on the keypad 202, the phone 200 is able to combine a 
first concurrent input (button press) with a second concurrent input (tilt status) to identify 
an entered character. Thus, the number of unique characters that may be entered is 
greater than the number of buttons (and the number of detectable tilt states). 

In a preferred embodiment, the first and second axes 208 and 210 are chosen so 
that as a user holds the phone 200 with the display 204 facing the user, the first axis 208 
runs through the left and right sides of the phone 200, so that rotation about the firet axis 
208 produces a forward and backward tilt. The second axis 210 preferably runs through 
the top and bottom of the phone 200, so that rotation about the second axis 210 produces 
a side-to-side tilt. Selecting the axes 208 and 210 in this way, as opposed to selecting an 
axis coming perpendicular out of the face of the phone 200, will allow the user to 
generally view correctly oriented text on the display 204 (i.e., the text will generally run 
horizontally from the user's frame of reference). Rotation about an axis coming 
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peipendicular out of the face of the phone 200 would require the user to read text at an 
angle. Comfort and ease of operation may also help in determining the axes of rotation. 

In most embodiments, the amount of tilt required for disambiguation is selected 
so that the user will still be able to easily view the keypad and display at all tilted states. 
Therefore, while a 90 degree tilt to the left may be detected as a disambiguating tilt, a 
more reasonable minimum tilt might be 5-10 degrees, with an average expected tilt of 
about 30 degrees. The amount of tilt should be large enough to avoid erroneous 
disambiguation, but small enough to promote comfort, speed, and ease in viewing the 
display and keypad. 

FIG. 3 is a simplified block diagram illustrating a system 300 for concurrent data 
entry in a portable device, such as a mobile phone. The system 300 includes a 
microprocessor 302 having connections to a tilt sensor 304 and a keypad 306. The 
system also includes a display 308 to allow a user to view entered text and other 
information, such as a message received torn another mobile user. 

The microprocessor 302 operates using software 3 10 and memory 3 12. The 
software 310 preferably runs on an operating system associated with the system 300, such 
as a mobile phone operating system. The software may include one or more modules 
such as a tilt/text engine 3 1 4 operable to identify entered data by using tilt and button 
presses as inputs. The software may be written in Java, C++, or any other suitable 
language. 

The memory 312 may include a sample record stack 316 to store a recent samples 
obtained by the microprocessor 302 fiom the tilt sensor 304. This may be useful in 
determining tilt relative to previous orientations, such as if a relative tilt implementation 



isused. Arelativetiltembodimentisdescribedingreaterdetail below. Thenumberof 
samples to be stored in the sample record stack 316 will likely depend on a number of 
factors, including the available memory, the sampling rate, and possibly a user defined 
setting that may be changed as the user becomes more proficient (and quicker) entering 
data using button presses concurrently with tilt. 

In an alternative embodiment, the tilt sensor 304 could make use of a digital 
camera, such as one contained in a "camera phone" to help in detennining tilt. For 
example, by identifying a visual pattern in a first image and identifying how the visual 
pattern has changed in a second or other subsequent image, the change in orientation (or 
tilt) of the system 300 may be determined. This alternative technique may be useful in an 
enviromnent subject to underlying backgn,und accelerations that might be perceived as 
accelerations (or tilts) by the tilt sensor 304. For example, a user entering data on an 

accelerating bus may observe effects due to the tilt sensor sensing acceleration from the 
bus in addition to acceleration fi-om an intentional tilt. 

While the embodiment of FIG. 3 makes use of software for a majority of 
operations, a hardware or firmware implementation could also be used. For example, a 
series of AND/OR gates implemented with t^sistors and/or programmable logic 
circuitry. 

FIG. 4 is a series of pictorial diagrams illustrating an exemplary embodiment for 
determining tilt in a system for concurrent data entry in a mobile phone. The series of 
figures show one possible combination of tilt axes that may be used to disambiguate the 
meaning of button presses. Tilting the phone to the left (left diagram) selects the first 
letter ofthe button, tiltingthephoneawayfiom the body(topdiagram)selects the second 



10 



letter of the button, tilting to the right (right diagram) selects the third letter, and, if a 
fourth letter is present on the button, tilting towards the user's body (bottom diagram) 
selects the fourth letter. Pressing a key without tilting (center diagram) results in entering 
the numeric value of the key. Space and backspace operations may be carried out by 
pressing unambiguous single-function buttons. 

Supporting both lowercase and uppercase characters would require a further 
disambiguation step since a total of seven characters per key would need to be mapped 
for keys 2-6 and 8, and nine characters each for the 7 and 9 keys. Adding case sensitivity 
could be done by either requiring the pressing of a "sticky" shift-key, or considering the 
magnitude of the tilt as a disambiguator where greater magnitude tilts result in upper case 
letters. FIG. 5 illusttates the latter of these two techniques for the "7" key and the letters 
'*P", "Q", "R", and "S" on a mobile phone. Eyes-free entry, however, would likely be 
more difficult using the technique shown in FIG. 5, since the user may wish to confirm 
that a large enough tilt was used to realize a capital letter. 

The system uses the standard 12-button mobile phone keypad augmented with a 
low-cost tilt sensor. The system uses a combination of a button press and tilting of the 
device to determine the desired letter. This technique differs from TUtType (Partridge et 
al. (2002), "TiltType: accelerometer-supported text entry for very small devices," 
UIST Symposium on User Interface Software and Technology, pp. 201-204.) in the size of 
the device, the type of keypad used, ease of one-handed operation, and in the sensing 
algorithms, described in detail below. The standard phone keypad mapping assigns three 
or four alphabetic characters and one number to each key. For example, the "2" key also 
has the characters "a", "b", and "c" assigned to it. The system assigns an additional 
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mapping by specifying a tilt direction for each of the characters on a key, removing any 
ambiguity from the button press. The user presses a key while simultaneously tilting the 
phone in one of four directions (left, forward, right, back) to input the desired character. 
For example, pressing the "2" key and tilting to the left inputs the character "a", while 
tilting to the right inputs the character "c". By requiring only a single keypress and slight 
tilt to input alphanumeric characters, the overall speed of text entry can be increased. 
Further, unlike some techniques that improve on die statiis quo MultiTap technique, the 
system is not language dependent, and Uius can be used without visually attending to the 
display screen. 

Techniques for Calculating Tilt 

The tilt of the phone is taken as whichever direction has the greatest tilt relative to 
an initial "origin" value. Described herein are three alternative embodiments for 
determining the tilt value: key tilt, absolute tilt, and relative tilt. 

a. Key Tilt 

In a first embodiment. Uie amount of tilt is calculated as tiie difference in the 
value of the tilt sensors at key down and key up. This requires the user to carry out tiiree 
distinct movements once the button has been located: push the button, tilt the phone, and 
release the button. A simitar approach has been used with a watch-like four-button 
device. (See Partridge. K.. Chatterjee, S.. Sazawal, V.. Borriello, G.. & Want. R. (2002). 
•TiltType: accelerometer-supported text entry for very small devices." ^Q/ VIST 
Symposium on User Interface Software and Technology, pp. 201-204.) Initial 
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experiments using a key tilt implementation on a 12-button mobile phone keypad showed 
that this implementation was much slower than the traditional MuUiTap technique. 

b. Absolute Tilt 

In a second embodiment, the tilt sensor's value at any given time is compared to a 
"fixed" absolute origin. Only two distinct movements are required to enter a character: 
the phone is tilted and then a key is pressed, to contrast, the key tilt embodiment requires 
three movements: a key is pressed, the phone is tilted, and then the key is released. 

However, users do not typically maintain a constant arm posture. Thus, in order 
for the tilt value to be meaningful, the fixed origin will preferably be reset every time the 
user's gross arm posture changes. 

Further, when using the system to enter two characters requiring tilt in opposite 
directions, more movement is required using this absolute approach, since the first tilt 
must be undone, then the new tilt applied. For example, entering the letters "ac" using 
the "2" key requires an initial tilt of some angle a to the lea to enter the "a". Then, the 
user has to tilt the same angle /? in tiie reverse direction to return to the origin, before 
tilting another angle 0 to the right to enter the letter "c". The total amount of movement 
is 2& + a, instead of the smaller a + ^ that one may expect However, one advantage of 
this embodimem over the key tilt embodiment is that if successive characters with the 
same tilt direction are to be entered, tiien the user can keep the phone tilted at tiiat 
direction for the successive keypresses. 
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c. Relative Tilt 



According to a third embodiment, tilt is calculated relative to a floating origin that 
is set when a tilt gesture begins. The begimiing of a gesture is detemiined by 
continuously watching for a change in orientation or a change in the direction of a tilting 
gesture. This approach solves both problems ofthe absolute tilt embodiment. Since all 
tilts are relative to the begimiing ofthe gesture, there is no absolute origin that need be 
reset when changing arm position. Further, opposite-direction tilts do not require double 
tilting, since the second tilt's origin is the end ofthe finst tilt's gesture. So. entering the 
letters «ac" requires a tilt of some angle a to the left to enter a, then another tilt of angle 0 
to the right to enter the c. for a total movement of a + j8. Note that, like with the absolute 
tilt embodiment, when entering only letters, we can enter successive character with the 
same tilt direction without re-tilting the phone, by looking at the last significant tilt. 
Disambiguating Characters 

Once a tilt state has been determined for a pressed button, a character associated 
with the pressed button may be identified by referring to a tilt menu that specifies tilt 
states that correspond to particular characters. Tlie tilt menu may be, for example, a 
simple lookup table stored in memory. Alternatively, disambiguation may be performed 
in hardware, such as in dedicated logic circuitry. 

Experimental Verification 

To confirm that embodimems ofthe present invention do indeed provide speed 
and efficiency benefits over the current MultiTap technique, an experiment was 
conducted, as described below. 
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Hardware 

A Motorola i95cl mobile phone equipped with an Analog Devices ADXL202EB- 
232 2-axis accelerometer board to enable tilt sensing served as the test device. TTie 
accelerometer board was connected to the phone via a serial cable (with the addition of 
an external power line). While a preferable commercial implementation is likely to have 
the tilt-sensing circuitry enclosed within the casing of the mobile phone, the external 
serial-cable mounting served to provide an indication of expected results. 

An implementation of a relative tilt system would require regular sampling from 
the tilt sensor. Because the experimental hardware provided for a reliable sampling rate 
of only approximately 10 Hz. an absolute tilt approach to tilt determination was used. To 
implement a relative tilt technique, at least a 20-50H2 sampling rate should be used. 

Under the absolute tilt experimental setup, the user was allowed to reset the origin 
at any time by holding the phone at the desired orientation and pressing "0". The 
additional movement required by this approach, however, was believed to be acceptable 
for evaluation purposes because if the experimental system performed well despite this 
additional movement, then any more robust implementation using a relative tilt approach 
would likely only perform better. In other wonls. the evaluation was biased against the 
experimental system. 

Because the ADXL board was able to detect a tilt of only fractions of a degree, 
only a very small tilt of the phone was necessary to disambiguate a button press. The 
maximum of the tilt in either axis was taken to be the intended tilt, with a 10% bias 
towards forward^ack. This bias was included due to a tendency of use,, to pitch to the 
dominant side when tilting forward with the wrist. 
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Software 

The software to read tilts and render text, as well as conduct the experiment, was 
written in Java 2 Micro-Edition using classes from both the Mobile Devices Information 
Profile (MIDP 1.0) and proprietary i95cl specific classes. 

The experiment was conducted witirely on the mobile phone rather than 
simulating a mobile phone keypad on some other device. All software, including those 
portions implementing the text entry techniques and data presentation and collection ran 
on the phone. No connection to an external computing device beyond the tilt sensor was 
used. 

The MultiTap implementation set up for comparison used the i95cl's built-in 
MultiTap engine, with a 2 second timeout and timeout kill. We only considered 
lowercase text entry in this evaluation. As such, the MultiTap engine was modified 
slightly to remove characters fi-om the key mapping that were not on the face of the 
button, so that the options available were only the lower case letters and numeral on the 
key. 

Procedure 

Experiment participants (5 men and 5 women of whom 3 were left-handed and 7 
right-handed, none of which had any experience composing text using either technique) 
entered short phrases of text selected from among those in MacKenzie's English phrase 
dictionary (see www.Yorku.ca/mack/Dhrases2.tvtV The desired text phrases were shown 
to participants on the screen on the phone. 

Timing began when participants entered the first character of the phrase, and 
ended when the phrase was entered completely and correctly. If an erroneous character 
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was entered, the phone alerted the user by vibrating, and the user was required to correct 
their error. With this procedure, the end result was error-free in the sense that the correct 
phrase was captured. Also, the phrase completion time incorporates the time taken to 
correct for errors. 

Before beginning each treatment, participants were told to read and understand 
the displayed phrase before entering it, and were given instructions for that treatment as 
follows: 

MuUiTap instructions: to enter a character using the MultiTap technique, first find the key 
that is labeled with that character. Press that key repeatedly until the desired character is 
reached. Press once for the first character, twice for the second, three times for the third, 
and, if present, four times for the fourth. Once you have found the correct letter, and are 
ready for the next one. you simply repeat the process. If the letter you wish to enter next 
is on the same key, you must first either press the "right" arrow on the phone or wait two 
seconds for the cursor to advance. 

Experimental svstem instmctmns- the technique works by tilting the phone in the 
direction of the letter you wish to enter, then pressing the key on which it is inscribed. 
For the first letter, tilt left. For the second letter, tilt forward. For the third letter, tilt to 
the right. For the fourth letter, tilt towards you. The direction of tilt is measured relative 
to the "centre" or "origin" position of the phone. You can reset the origin at any time by 
pressing the "0"key. 

The experimenter then demonstrated the relevant technique. To ensure that 
participants understood how the technique worked, they were asked to enter a single 
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phrase that would require tilting in all four directions for the experimental system, or two 
successive letters on the same key for MultiTap. 

Additional instructions were given for both techniques to describe space and 
delete keys, as well as to enter an extra space at the end of the phrase to indicate 
completion. The process for enor correction was also explained to them. Participants 
were also directed to rest as they liked between phrases, but to continue as quickly as 
possible once they had started entering a phrase. 

Results 

The data collected from 10 participants took an average of 10.3 minutes per 
block. A total of 145360 coirect character, of input were entered for the 6400 phrases. 
Text Entry Speed 

We use the standad wpm (wordi^per-minule) measure (o deseribe text enhy 
sp«d. TOsistiadilionallycalcuIatedasoharac.eBpersecond.60/5. Beeauselimmg 
in o„ experiuKM staned only after entertag the fin, chan^ter, that cha™=,er was not 

included in oakuteions of entty speed. Thus, for the pun^sesofthesecomputadons,*^ 
length of a ptoas. is n-l character,. Also, to signify oHnpMon. u«n, had to enter an 
extra spaee at the end of each phrase. However, ent^. of the last real chanKter of the 
phrase was considered to be the end time. 

The average text entry speed for all blocks were 1 1.76 wpm and 10.1 1 wpm for 
the experimental system and MultiTap respectively. Overall, the system was I6.30/0 
faster than MultiTap. 
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The means for the first block of trials were 7.42 wpm and 7.53 wpm. for the 
system and MultiTap respectively. Performance in both techniques increased steadily, 
with the means for the last (16*) block of trials of 13.57 wpm for the system and 1 1.04 
wpm for MultiTap. While subjects perfomied marginally better with Mw/ftTop initially, 
they improved considerably faster with the experimental system, with the spread between 
the techniques reaching 22.9% in favor of the experimental system by the end of the 
experiment. 

Analysis of variance indicated significant main effects for technique (F,^ = 615.8. 
p < .0001). and block {F^s.m= 145.2.p < .0001). There was also a significant technique 
X block interaction (F,5,2o= 20.5.p < .0001). indicating that participants improved at 
different rates for the different techniques. FIG. 6 illustrates these effects. 

From our analysis and FIG. 7. we see that without prior experience with either 
technique, the system started out perfonning worse than MultiTap. only crossing over at 
block 4. This is likely because the system required participants to master two distinctly 
different motor skills: pressing the key. and tilting the phone. MultiTap required only a 
single type of motor action: multiple presses of the key. 

FIG. 8 shows data after participants switched techniques (i.e.. the second half of 
the experiment). We see here that the system starts off faster than MultiTap, indicating 
that participants' were able to take advantage of and transfer their previous experience 
with MultiTap in the first half of the experiment. This is a positive indication since it 
means that real users with lots of experience with MultiTap can transfer at least some of 
that skill if they switch to the experimental system. Note, however, that there is quite a 
bit more variability in the performance for the experimental system, as indicated by the 
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poorer fit of the power curve as compared to FIGs. 6 and 7. This indicates that 
participants experienced some level of interference due to previous experience with 



MultiTap. 
Error Rates 



Given that the experimental procedure required participants to make corrections 
as they proceeded, with an end result of a completely correctly entered phrase, the entry 
speed results discussed previously incorporate the cost of error correction. However, it is 
still useful to look at a more explicit error rate. We calculate percentage etror rate as the 
number of characters entered that did not match the expected character, divided by the 
length of the phrase. In this case, we used the actual length of the phi^se. and not (n-l) as 
in the wpm rate. 

Overall, em,r rate ™„ch higher for the experimemal system (I I %) than for 
MMTopO%). ™=eir=ctwass.atisticallysig„ifleam(f„=1378.8,;,<.0001). Tl,ere 
was,.«, a sWficanteffeo, for blocks (F,,,,. 2,.,,, < .000,,. A significant techni,„e 
X M«>lc interaction (f 23.3. p < .0001) and FIG. 9 indicate a,« while the enor rat« 
for MulUTap rm^„ q„i,e constant diroughout the experiment, the etor rates for the 
experimental system dmp rapidly over the «,« 8 blocks, and begin to asymptote Som 
block 9 onwards. 

As with the entry time analysis, a significant order x technique interaction (F,5,«. 
= 168.9.;, < .0001) indicates that participants exhibited asyn,n,einc transfer effects. An 
analysis of the fir.t half of the data (i.e.. before participants switched techniques) 
indicates main effects similar to that of the entire dataset: technique (F, , = 632.4. p < 
.0001). blocks (F,,.o= 7.3,p< .0001). and technique x block interaction (F,,,^= ,0.4. 
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P < .0001). as shown in FIG. 10. Interestingly, the mean system error rate (8.6%) was 
lower than for the entire data set. indicating that the lack of interference from MultiTap 
was beneficiaK 

FIG. 1 1 illustrates the data from trials in the second half of the experiment (i.e.. 
afterparticipantsswitched techniques). Comparing this to FIG. 10. the mean the system 
error rate of 1 3.50/0 is much higher than the mean 8.60/0 rate in the first half of the 
experiment. Further, the fir.t 8 blocks of frials did not exhibit a constant trend for the 
experimental system. Clearly, participants' previous experience with the MukiTap 

technique was havingadetrimental effect on their ability to use the experimental system 
rightaftertheswitchintechniqueoccurs. This is consistent with the effect observed in 

the text entry speed data illustrated earlier in FIG. 8. However, this effect wears off 
roughly after block 8. 

To examine the cause of Oie higher system enx-r rate, eno« may be g^uped io,„ 
^v. categories:,/,,..™,, and i„„o„«.„,,w,^„^^^„^^^^^^._^^ 
cncered a letter a». appears on fte same button as U,e co™. letter, indicating to. an 
enoneous .il< was made. BuUon errors are those where the participant entered a letter 
that appeared on a different button. 

We had anticipated that button errors would have similar rates for the system and 
MultiTap. However, the results showed a significant difference (/•,^= 320.67,;, < 

. (^a.7). where 30/0 of characters enters in the ^„/«T.p trials were 

1.50/0 of characters entered in the experimental system showed this type of enx,r. 

Reconciling this low button error rate with the high overall error rate for the 
system, it is clear that most of the erto« committed while using the system were tilt 
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errors. Breaking down the tilt error rate by letter shows that participants committed 
significantly more enore for some letters than others (F2„oo= 2Al,p < .001), as Figure 
10 illustrates. 

Analysis of variance showed a significant main effect for tilt direction on tilt 
error rate {F.^^ 37. 6, P < .0001). Pairwise means comparisons showed a significantly 
higher tilt error rate for those letters requiring forward or backward tilting than those 
requiring right or left tilting. In particular, backwards tilt results in significantly higher 
errors than all the other tilt directions. FIG. 12 illustrates this trend. 

As was discussed previously, the overall system error rate decreases with practice. 
As such, it is possible that the high tilt error rate for backward tilt (letter? "s" and "z") is 
due to the limited amount of practice users had with entering the letter "z", which was 
only entered 3 times in the experiment by each participant. However, the other letter that 
required backward tilting, "s". also showed a similarly high //// error rate, despite being 
entered very frequently during the experiment. In other words, additional practice did not 

seem to decrease the backward tilt error rate significantly, indicating that users had an 

inherent difficulty with backward tilting actions. FIG. 13 illustrates tilt error rates as a 

percentage for each letter in the alphabet. 

When participants committed a tilt error for a letter requiring a left or right 

gesture. 82% of the time they ended up entering the forward-tih letter on that button. 

This indicates that the 10% bias we introduced in our algorithm seems to 

overcompensate. Reducing this compensation factor may lower tilt error rate for 

left/right tilts. 
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The increased error rate for forwa^d^ackwaK^ movements is possibly explained 
by limitations of the absolute tilt system used in our experiment. Participants tended to 
set the origin, then have the phone slowly "creep" forward as they made far more forward 
than back tilting gestures. As a result, the phone was always tilted somewhat forward. 
This meant that an exaggerated back gesture was required to enter "s" or "z", which users 
often failed to accomplish on the first attempt. The tendency to hold the phone in a 
forward position also explains why most tUt errors resulted in entering the forward tilt 
letter on the same button. Due to hardware constraints, an absolute tilt implementation 
was used, instead of the more efficient and accurate relative tilt method. Eiror rates 
would likely be improved if relative tih were to be used, since users would not have to tilt 
a specific amount past the origin between characters as required in the absolute tilt 
method, and they also would not have to exaggerate the back tilts to overcome the 
forward posture. These extra requirements are a likely cause of errors, particularly if 
users attempt to perform the technique quickly without watching the screen. Relative tilt 
would be more amenable to fast, "eyes-free" use. 

The tilt angle required ranges from a little more than 0 degrees to an approximate 
maximum of 90 degrees. From our observations of participants in our experiment, it 
appears that the average tilt angle is probably around 30 degrees. With a more definitive 
detemiination of this parameter or at least a smaller bound on its range, it would be 
possible to develop a model that more accurately describes the system than KSPC. 

We will also examine whether different tilting directions are more natural for the 
wrist, and perhaps replace the simplistic "lefl/right. back/forward" technique examined 
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here. We will also test an implementation that groups letters to minimize the need to re- 
tilt between character entries. 
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CLAIMS 

I claim: 

1. A system for data entry in a portable device comprising: 

a keypad having a plurality of buttons, at least one of the buttons being 
associated with two or more characters; 

a tilt sensor operable to detect a tilt subjected to the portable device by a 
user; and 

a processor programmed to identify one of the two or more characters 
based on one of the plurality of buttons being pressed concunently with the tih 
subjected by the user. 

2. TTie system of Claim 1 . wherein the portable device is a mobile phone having a 
front face, left and right sides, and a top and bottom, and wherein the keypad is a standard 
12-button alphanumeric keypad located on the front fece of the mobile phone. 



3. The system of Claim 2. wherein the tilt is detected along a first 



axis. 



4. The system of Claim 2. wherein the tilt is detected along a fim axis and a second 



axis. 



5. The system of Claim 4. wherein the first and second axes are in a plane parallel to 
the fi-ont face of the mobile phone. 



25 



6. The system of Claim 4. wherein the first axis runs through and is perpendicular to 
the left and right sides of the mobile phone, wherein the second axis runs through and is 
perpendicular to the top and bottom, and wherein when the face of the mobile phone is 
facing a user, a tilt to the left along the second axis identifies a first character, a tilt away 
ftom the user along the first axis identifies a second character, a tilt to the right along the 
second axis identifies a third character, and no tilt identifies a fourth character. 

7. The system of Claim 6, wherein a tilt toward tiie user along the first axis identifies 
a fifth character. 



8. The system of Claim 6, wherein the fourth character is a numeral and the first, 
second, and Uiird characters are letters located on a first button associated with the 
numeral on the standard 12-button keypad. 

9. A method for entering data on a portable device having a standard twelve-button 
keypad, comprising: 

determining a tilt of the portable device when a first button on the keypad 
has been actuated; and 

disambiguating €mm among a plurality of characters associated with the 
first button by comparing the determined tilt to a predefined tilt menu associated 
with the first button. 
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10. The method of Claim 9. wherein the tilt is detemiined concurrently with the first 
button being actuated. 



11. The method of Claim 9, wherein the portable device is a mobile phone having a 
display located on a front face, left and right sides, and a top and bottom, and wherein the 
keypad located on the front face of the mobile phone. 



12. The system of Claim 1 1, wherein the tilt is detemined along a firet 



axis. 



13. The system of Claim 1 1. wherein the tilt is determined along a firet axis and i 
second axis. 



14. The system of Claim 13, wherein the first and second axes are in a plane parallel 
to the fiont face of the mobile phone. 

15. The system of Claim 13. wherein the first axis nms through and is perpendicular 
to the left and right sides of the mobile phone, wherein the second axis runs through and 
is perpendicular to the top and bottom, and wherein when the face of the mobile phone is 
facing a user, a tilt to the left along the second axis identifies a first character, a tilt away 
from the user along the first axis identifies a second character, a tih to the right along the 
second axis identifies a third character, and no tilt identifies a fourth character. 
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16. The system of Claim 15, wherein a tilt toward the user along the first 
identifies a fifth character. 



17. The system of Claim 15, wherein the fourth character is a numeral and the first, 
second, and third characters are letters located on a first button associated with the 
numeral on the standard 12-button keypad. 

1 8. A method for disambiguating from among a pluraUty of character associated 
with a first button on a 12-button keypad on a mobile phone, comprising: 

sampling tilt along two axes parallel to a front face of the mobile phone; 

maintaining a sample stack indicative of a past tilt samples; 

upon detecting the first button being pressed by a user, determining a tilt 
state by comparing a most recent tilt to at least one of the past tilt samples; 

upon determining that the tiU state falls within a first tih threshold, 
identifying a numeral associated with the first button; 

upon detemining that the tilt state falls within a second tilt threshold, 
identifying a first character associated with the first button; 

upon determining that the tilt state falls within a third tilt threshold, 
identifying a second character associated with the fust button; and 

upon determining that the tilt state falls within a fourth tilt threshold, 
identifying a third character associated with the first button. 
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1 9. The method of Claim 1 8, fiirther comprising upon determining that the tilt state 
falls within a fifth tilt threshold, identifying a fourth character associated with the first 
button. 

20. The method of Claim 18, wherein the first, second, and third characters are lower- 
case letters, and wherein, upon determining that the tilt is greater than a predetermined 
capital threshold, identifying a capital letter associated with the first button. 

2 1 . The method of Claim 1 8, wherein tilt is sampled using a tilt sensor and a 
microprocessor. 

22. The method of Claim 2 1 , wherein the tilt sensor includes at least one acceleration 
sensor. 

23. The method of Claim 2 1 , wherein the tilt sensor includes at least one digital 
camera. 
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ABSTRACT 

A system and method for entering data on a portable device includes detennining 
a tilt state as a button is being pressed. The determined tilt state can be used to 
disambiguate from among a plurality of characters associated with the pressed button. In 
a prefenred embodiment, the portable device is a mobile phone and the button is part of a 
standard 12-button keypad. 
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Figure 7. Error rates (%) 
by technique and block 
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Figure 8, Error rates 
(%) by technique and 
block for the first half of 
the experiment, befdrB 
parUcipants switched 
techniques 
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